Internet caller identification system and method

ABSTRACT

The present invention is an Advanced Intelligent Network (AIN) based system and method that allows a subscriber connected to the Internet via a dial-up connection to receive caller identification information concerning an incoming telephone call. The information may be provided via a pop-up dialog box on the subscriber&#39;s display, which includes but is not limited to a monitor of a personal computer (PC). The information displayed to the subscriber includes the name and number of the calling party, if available. In addition, several disposition options are presented to the subscriber solely via the Internet which, upon selection, determine the handling of the incoming call.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.10/885,680, filed on Jul. 8, 2004, which is a continuation of U.S.patent application Ser. No. 09/545,459, filed on Apr. 7, 2000, now U.S.Pat. No. 6,816,481, which claims the benefit of U.S. Provisional PatentApplication No. 60/128,474, filed on Apr. 9, 1999, the disclosures ofwhich are expressly incorporated herein by reference in theirentireties.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to the field of telecommunications. Moreparticularly, the present invention relates to a telecommunicationssystem for allowing a subscriber connected to the Internet via a dial-upconnection to receive notification and caller identification informationconcerning an incoming telephone call. Further, the invention providesthe subscriber with various disposition options for handling theincoming telephone call.

2. Acronyms

The written description provided herein contains acronyms which refer tovarious telecommunications services, components and techniques, as wellas features relating to the present invention. Although some of theseacronyms are known, use of these acronyms is not strictly standardizedin the art. For purposes of the written description herein, acronymswill be defined as follows:

Advanced Intelligent Network (AIN)

Central Office (CO)

Called Party Number (CDN)

Calling Party Number (CPN)

Call Processing Record (CPR)

Data and Reporting System (DRS)

Heartbeat Server (HS)

Integrated Service Control Point (ISCP)

Interactive Voice Response (IVR)

Internet Call Waiting Server (ICWS)

Internet Caller Identification (ICID)

Line Information Database (LIDB)

Local Access and Transport Area (LATA)

Local Exchange Carrier (LEC)

Local Routing Number (LRN)

Numbering Plan Area-Central Office Code (NPA-NXX)

Personal Computer (PC)

Public Switched Telephone Network (PSTN)

Registration Server (RS)

Service Control Point (SCP)

Service Switching Point (SSP)

Signaling System 7 (SS7)

Signaling Transfer Point (STP)

Terminating Attempt Trigger (TAT)

Transaction Capabilities Application Part (TACP)

Transmission Control Protocol/Internet Protocol (TCP/IP)

3. Description of Background Information

In recent years, the number of households having Internet access hasgrown extraordinarily. In fact, having a home personal computer withInternet access is now commonplace. However, most households have onlyone telephone line which must be shared between a dial-up connection toan Internet Service Provider (ISP) and voice communications via thetelephone. This results in several problems, including missed telephonecalls and disconnections from the ISP.

When a telephone line is occupied during an Internet session, telephonecalls to that line are met with a busy signal. As a result, importantcalls are not able to be received by the called party until the line isunoccupied. Moreover, the caller has no way of knowing when the linewill be free and must continually attempt the call until the party isreached. Additionally, Internet subscribers have no way of knowing whoattempted to call them while they were on the Internet. If expecting acall, an Internet subscriber must wait for the call before connecting tothe Internet, or risk missing the call. Further, Internet subscribersmust deactivate their Call Waiting feature while they access theInternet, or risk undesirable disconnections when an incoming call isattempting to terminate to their line.

As a result, it would be desirable to be informed of an incomingtelephone call while being connected to the Internet. It would also bedesirable to know the name and number of the calling party, beforedeciding whether to abandon the Internet connection. It would further bedesirable to have a variety of incoming call disposition optionsavailable to an Internet subscriber.

One attempt at solving these problems was presented by MCMULLIN, U.S.Pat. No. 5,809,128. MCMULLIN discloses a method and apparatus forpermitting notification, identification, and control of incoming callsto a subscriber when the subscriber is connected to a DataCommunications Service (DCS) via a dial-up modem over the PublicSwitched Telephone Network (PSTN).

However, MCMULLIN does not provide a solution that takes advantage ofthe ubiquitous AIN environment. In fact, the system disclosed inMCMULLIN ignores the features of the AIN, instead relying upon a callforward busy/no answer number feature.

Specifically, MCMULLIN requires the subscriber to activate a callforward busy/no answer number feature which directs blocked calls orunanswered calls to a called party proxy. In circumstances where asubscriber has activated the call forward busy/no answer number featureand the subscriber is using their telephone link (e.g., engaged in datacommunications) and a second call is placed to the subscriber's line,the call is automatically routed to the proxy telephone link. Thismethod is slow, requires unnecessary processing, and occupies additionalresources. MCMULLIN also requires a dedicated communications channelbetween the central office and the DCS. This restriction unduly limitsthe subscriber's choice of Internet Service Provider (ISP). Given thesubstantial number of ISPs that exist, it would be impractical to have adedicated channel to each ISP.

The present invention overcomes the problems associated with the priorart.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is further described in the detailed descriptionthat follows, by reference to the noted plurality of drawings by way ofnon-limiting examples of preferred embodiments of the present invention,in which like reference numerals represent similar parts throughoutseveral views of the drawings, and in which:

FIG. 1 is a functional block diagram showing an exemplarytelecommunications network, according to an aspect of the presentinvention;

FIG. 2 is an exemplary ICID call flow diagram in which ICID has beendeactivated, or when no active Internet session exists, according to anaspect of the present invention;

FIG. 3 is an exemplary ICID call flow diagram in which the ICIDsubscriber elects to accept the incoming telephone call, according to anaspect of the present invention;

FIG. 4 is an exemplary ICID call flow diagram in which the ICIDsubscriber elects to forward the incoming telephone call to voice mail,according to an aspect of the present invention;

FIG. 5 is an exemplary ICID call flow diagram in which the ICIDsubscriber elects to play an announcement to the caller, according to anaspect of the present invention;

FIG. 6 is an exemplary ICID call flow diagram in which the ICIDsubscriber elects to redirect the incoming telephone call to analternate telephone number, according to an aspect of the presentinvention;

FIG. 7 is an exemplary ICID call flow diagram in which the calling partyabandons the telephone call to the ICID subscriber after a response fromthe ICW server, according to an aspect of the present invention;

FIG. 8 is an exemplary ICID call flow diagram in which the calling partyabandons the telephone call to the ICID subscriber before a responsefrom the ICW server, according to an aspect of the present invention;

FIG. 9 is an exemplary flowchart diagram of the ICID ISCP Service Logic,according to an aspect of the present invention; and

FIG. 10 is a continuation of the exemplary flowchart diagram of FIG. 9.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

In view of the foregoing, the present invention, through one or more ofits various aspects and/or embodiments is thus presented to provide anInternet caller identification system that operates within an AINenvironment.

Accordingly, one aspect of the present invention is to provide a methodfor allowing a subscriber connected to the Internet via a dial-upconnection to receive notification and caller identification informationassociated with an incoming call from a calling party to the subscriber.The method includes receiving the incoming call at a terminating switch,suspending the call at the terminating switch, launching a first queryin response to a request from the calling party to establish aconnection with the subscriber, and accessing an integrated servicecontrol point (ISCP) in response to the first query. The ISCP thenlaunches a second query to a Registration Server (RS) to determine thesubscriber's Internet status. The subscriber's Internet status relatesto whether the subscriber is connected to the Internet. The methodfurther includes receiving a response at the ISCP from the RS indicatingthat the subscriber is online, determining identification informationassociated with the calling party, playing a first announcement to thecalling party, to sending a message from an Internet Call Waiting Server(ICWS), solely via the Internet, to client software on the subscriber'scomputer, including notification and caller identification informationassociated with the incoming call. The subscriber's dispositionselection, is received at the ICWS solely via the Internet, a secondannouncement is played to the calling party, and the call is handledaccording to the subscriber's disposition selection. The subscriber isable to control disposition of calls while being connected to theInternet.

According to another aspect of the present invention, the handlingfurther includes routing the call from the terminating switch to adestination.

According to another aspect of the present invention, the identificationinformation includes a name and a telephone number of the calling party.

According to yet another aspect of the present invention, if thesubscriber's disposition selection is to accept the incoming telephonecall, the client software sends a de-registration request to the RS,terminates the Internet dial-up connection, and terminates the incomingcall to the subscriber. According to another aspect of the presentinvention, if the subscriber's disposition selection includes forwardingthe call to a voice mail service, the ISCP instructs the switch

to terminate the incoming telephone call to the subscriber and the callis then forwarded to the voice mail service. According to another aspectof the present invention, if the subscriber's disposition selectionincludes forwarding the call to another telephone line, the ISCPinstructs the switch to forward the incoming telephone call to theanother telephone line. According to another aspect of the presentinvention, if the subscriber's disposition selection includes playing amessage to the caller, the ISCP instructs the switch to play a messageto the caller.

According to another aspect of the present invention, the messageincludes advising the calling party to attempt the call later. Accordingto yet another aspect of the present invention, the message includesadvising the calling party that the subscriber will return the call.

According to another aspect of the present invention, the firstannouncement advises the calling party to hold the telephone line.According to another aspect of the present invention, the secondannouncement advises the calling party of the subscriber's selecteddisposition of the telephone call.

Accordingly, another aspect of the present invention is to provide asystem for allowing a subscriber connected to the Internet via a dial-upconnection to receive notification and caller identification informationconcerning an incoming call from a calling party. The system includes anIntegrated Service Control Point (ISCP) for storing processinginstructions for the subscriber and a switch associated with thesubscriber that receives the incoming call. The switch has an AINtrigger set to launch a query in response to a request from a callingparty to establish a connection with the subscriber and sends the queryto the ISCP in response to the trigger, receives routing instructionsfrom the ISCP, and plays announcements in response to instructions fromthe ISCP. The system further includes a Registration Server (RS) thatreceives registration requests from client

software and stores information related to the subscriber's onlinestatus. The RS responds to queries from the ISCP with information aboutthe subscriber's online status. A Heartbeat Server (HS) updates the RSwith the subscriber's online status, receives heartbeat messages fromthe client software via the Internet, and receives de-registrationrequests from the client software. An Internet Call Waiting

Server (ICWS) includes a communications interface between the ISCP andclient software, receives information from the ISCP, forwards theinformation to the subscriber solely via the Internet. Thecommunications interface receives the subscriber's disposition selectionsolely from the Internet, forwards the disposition selection to theISCP, and forwards de-registration requests from the client software tothe HS.

According to another aspect of the present invention, in response torouting instructions received from the ISCP, the switch routes the callin accordance with the instructions to its destination.

According to another aspect of the present invention, the clientsoftware communicates solely via TCP/IP utilizing the Internet with theRS, HS, and ICWS. According to another aspect of the present invention,the HS communicates with the RS solely via TCP/IP utilizing theInternet.

According to another aspect of the present invention, the systemincludes a terminal device storing the client software of thesubscriber. The client software alerts the subscriber to the incomingcall, sends registration and de-registration requests, and sends thesubscriber's disposition selection to the ICWS.

According to another aspect of the present invention, when thesubscriber's disposition selection comprises accepting the call, theclient software sends a de-registration request to the RS and terminatesthe Internet dial-up connection. The incoming call is then terminated tothe subscriber. According to another aspect of the present invention,when the subscriber's disposition selection includes forwarding the callto voice mail, the ISCP instructs the switch to terminate the incomingtelephone call to the subscriber and the incoming call is then forwardedto the voice mail service. According to another aspect of the presentinvention, when the subscriber's disposition selection includesforwarding the call to another number, the ISCP instructs the switch toforward the incoming telephone call to another telephone line. Accordingto another aspect of the present invention, when the subscriber'sdisposition selection includes playing a message to the caller, the ISCPinstructs the switch to play a message to the caller.

According to another aspect of the present invention, the messageadvises the calling party to attempt the call later. According toanother aspect of the present invention, the message advises the callingparty that the subscriber will return the call.

The present invention is an AIN based system and method that allows asubscriber connected to the Internet via a dial-up connection to receivecaller identification information concerning an incoming telephone call.The information may be provided via a pop-up dialog box on thesubscriber's display, which includes but is not limited to a monitor ofa personal computer (PC). The information displayed to the subscriberincludes the name and number of the calling party, if available. Inaddition, several disposition options are presented to the subscriberwhich, upon selection, determine the handling of the incoming call.

The disposition options available to the subscriber include acceptingthe call, forwarding the call to a voice mail system, redirecting thecall to another telephone line (e.g., a cellular telephone or a secondtelephone line), and playing an announcement to the calling party. Theannouncement played to the calling party is selected by the subscriberand may be either a message informing the calling party that the partythey are trying to reach is busy and that the caller should call backlater, or a message informing the calling party that the party they aretrying to reach is busy and will call them back later. Additionally, thesubscriber has the option of selecting the language in which themessages plays, e.g., English or Spanish.

FIG. 1 illustrates an exemplary telecommunications network 10 of thepresent invention. The network 10 includes a calling party 28, anoriginating Service Switching Point (SSP) 30, a terminating SSP 20, asubscriber's telephone 18, a subscriber's personal computer (PC) 25, adisplay 24, and client software 22. The network also includes aSignaling Transfer Point (STP) 65, a Local Number Portability (LNP)Database 60, a Line Information Database 50, an Integrated ServiceControl Point (ISCP) 40, an Internet Call Waiting Server (ICWS) 70, aRegistration Server (RS) 80, a Heartbeat Server (90), and the Internet100.

Exemplary client software 22 includes ICW Client, available fromSouthwestern Bell Telephone Company.

The SSP 20 is the terminating central office (CO) for the ICID (InternetCaller Identification) subscriber 18 and the SSP 30 is the originatingcentral office for the calling party 28; although, the terminatingoffice and central office may be the same. The SSPs 20 and 30 maycomprise, for example, 1AESS or 5ESS switches manufactured by LucentTechnologies, Inc., or DMS-100 switches manufactured by Nortel NetworksCorporation (Nortel), or AXE-10 switches manufactured byTelefonaktiebolaget LM Ericsson.

The 1AESS switches may use an AIN Release 0.1 protocol and should beequipped with Generic 1AE13.01 (or higher) software and associated AINSSP features. The 5ESS switches may utilize an AIN Release 0.1 protocoland should be equipped with Generic 5E12 (or higher) software andassociated AIN SSP features. The DMS-100 switches (release NA009) mayutilize an AIN Release 0.1 protocol and associated AIN SSP features. TheAXE-10 switches may utilize an AIN Release 0.1 protocol and should beequipped with Generic 8.07 (or higher) software and associated AIN SSPfeatures. The call service logic of the present invention may beupgraded to accommodate future AIN releases and protocols and futuretrigger types. Specifications of AIN Release 0.1 SSPs may be found inBellcore TR-NWT-001285, Switch-Service Control Point (SCP) ApplicationProtocol Interface Generic Requirements, the disclosure of which isexpressly incorporated by reference herein in its entirety.

In order to implement ICID, a Termination Attempt Trigger (TAT) isassigned to an ICID subscriber's directory number or line, dependingupon the type of switch. Once the trigger has been assigned andactivated, every terminating call to the ICID subscriber's line willcause the SSP 20 to suspend the call and send an AIN query message, viathe existing Signaling System 7 (SS7) network (and appropriate STPs 65),to the ICID subscriber's serving ISCP 40 for instructions.

The ISCP 40 stores a Call Processing Record (CPR) for each ICIDsubscriber and requests information from the other ICID networkelements. In particular, the ISCP 40 receives the TAT query from the SSP20 and responds to the SSP 20 with routing instructions for calls toICID subscribers.

The RS 80 receives registration requests from the client software 22when the subscriber logs on to the Internet 100 and activates the ICIDservice, and stores information related to the ICID subscriber's onlineInternet status. The RS 80 is the first database accessed by the ISCP 40during the processing of an ICID call. Based upon the informationprovided in a GetData query, the RS 80 returns a response containinginformation associated with requested data elements to the ISCP 40. Forexample, the RS 80 responds to the GetData query from the ISCP 40 withinformation about the ICID subscriber's Internet session status.

A GetData query, sent via Transmission Control Protocol/InternetProtocol (TCP/IP), includes an identifier, a service key, and a dataelement. The identifier indicates that the query is a GetData query, theservice key contains an indication of the ICID subscriber for whichinformation is requested and, optionally, security information. The dataelement is the calling party's name being retrieved.

Additionally, the ISCP 40 uses the LIDB 50, a database, to retrievecalling party name information associated with the calling party'stelephone number for transmission to the ICID subscriber via the ICIDapplication. The interface between the LIDB 50 and the ISCP 40 is theBellcore GetData query provided over the SS7 network. With thisinterface, the ISCP 40 can receive data from the LIDB 50. To support theGetData query, the ISCP 40 accesses the LIDB 50 with the line number ofthe calling party in order to obtain the calling party name. Detailedinformation about the GetData interface may be obtained in BellcoreGR-2838-CORE, Generic Requirements for GetData, the disclosure of whichis expressly incorporated by reference herein in its entirety.

If it is determined that the subscriber is online, the ISCP 40 queriesthe LNP Database 60, in a known manner, to determine if the callingparty number received in the TAT query has been ported. The telephonenumber received in a response from the LNP database is used to determinethe calling party name, when it is available.

The ICWS 70 is the communications interface between the ISCP 40 and theICID client software 22 on the subscriber's terminal. Specifically, theICWS 70 receives information related to ICID incoming calls from theISCP 40 and passes this information directly to the ICID subscriber viaTCP/IP utilizing the Internet 100. Further, the ICWS 70 passesde-registration requests from the client software 22 to a HeartbeatServer (HS) 90.

Additionally, the ISCP 40 provides the ICWS 70 with the client softwareversion number running on the subscriber's PC 25. Subsequently, the ICWS70 determines if the subscriber has the latest version of the clientsoftware. If the ICWS 70 determines that the subscriber does not havethe latest version of the client software, it notifies the subscriberthat they need to update their client software. This notification isgiven when the ICWS 70 passes the caller identification information tothe subscriber.

During the course of an active Internet session with ICID service turnedON, the client software 22 periodically transmits heartbeat messages viaTCP/IP utilizing the Internet 100 to the HS 90. In response, the HS 90updates the RS 80 via TCP/IP with the subscriber's online status, andnotifies the RS 80 in situations where there is an interruption ofheartbeat messages from the client software 22, indicating a possibleundesired disconnection of the Internet session. Additionally, if thesubscriber currently connected to the Internet 100 elects to accept anincoming telephone call (as will be discussed later), the clientsoftware 22 sends a de-registration request, which is passed to the HS90.

After the RS 80 receives a registration request from the client software22, the RS 80 sends a heartbeat setup message to the HS 90 via TCP/IP toalert it to expect to receive heartbeat messages from the client. As aresult, the HS 90 begins to receive keep-alive messages from the clientafter the registration is completed. If the client sends a keep-alivemessage that does not match the information in the HS 90 memory, thenthe HS 90 sends a registration database query to the RS 80 via TCP/IP.If the query results match the data received, the copy in memory isupdated. If the results of the query do not match, the HS 90 opens a TCPsession to send a message instructing the client to re-register with theRS 80.

The interface between the ISCP 40 and the RS 80 and between the ISCP 40and the ICWS 70 is the Bellcore Generic Data Interface (GDI) for(TCP/IP). This interface provides the capability to send/receivetransactions to and from external systems over TCP/IP using TransactionCapabilities Application Part (TCAP) messages. The ISCP 40 can get data,send data, or invoke an application (InvokeApp) from a database such asthe RS 80 or ICWS 70. More information may obtained from BellcoreSR-3389, ISCP Generic Data, Interface Specification for TCP/IP, Version5.0, Issue 2, January 1997, the disclosure of which is expresslyincorporated by reference herein in its entirety.

The Internet Caller Identification Client Software 22 is the subscriberinterface for the ICID service. The client software 22 permits thesubscriber to turn the ICID service ON or OFF as desired, choose presetoptions, and select call disposition options. An InvokeApp message isused to invoke the ICID application on the ICWS 70 and to return theICID subscriber's selected disposition option. Additionally, the clientsoftware 22 provides a visual and audible alert to the subscriber of anincoming telephone call, sends Internet registration and de-registrationrequests, sends the subscriber's option selection to the ICWS 70, andsends heartbeat messages to the HS 90.

An InvokeApp message, sent via TCP/IP, consists of an originating SysIDidentifying the client sending the message, an accessID identifying thesending client process at the sending site, a receiverID identifying theserver software system receiving the request, an appName identifying theapplication process within the receiving server software, an actionIDidentifying the type of requested action, a securityID, and a set oftagged parameters.

Exemplary call flows, according to an embodiment of the invention willnow be discussed. FIG. 2 is an ICID call flow diagram in which the ICIDservice has been turned OFF, or no active Internet session exists. Atstep 1, a telephone call is placed to an ICID subscriber. A TAT in theterminating CO SSP 20 causes the call to be suspended at the SSP 20. Thetrigger also causes the SSP 20 to transmit an AIN query messageincluding the CPN (if available) and called party number (CDN) via theSS7 network and the appropriate STPs 65 to the ICID subscriber's servingISCP 40 at step 2. At step 3, the ISCP 40 sends a GetData query to theRS 80 with the called party's telephone number to request the onlinestatus of the ICID subscriber. At step 4, the ISCP 40 sets a timer equalto a predetermined time, e.g., 2 seconds. In the event that the RS 80does not respond within the predetermined time (indicating a timeoutcondition) or responds with an error, the ISCP 40 sends an AuthorizeTermination response to the SSP 20. As a result, the SSP 20 terminatesthe suspended telephone call at the subscriber's line and the call mayencounter features programmed on the line, e.g., call waiting, callforwarding, etc.

If it is determined at the RS 80 that the subscriber is not currentlyonline or the subscriber has the ICID turned OFF, the RS 80 respondswith a “0”. In this scenario, because the subscriber is not online orthe subscriber has the ICID turned OFF, the RS 80 responds to the ISCP40 at step 5 with a “0”. The ISCP 40 then sends an Authorize Terminationresponse to the SSP 20 at step 6, which terminates the call to thesubscriber's telephone line at step 7. As a result, a connection is madebetween the calling party and the subscriber. As the call attempts toterminate, it encounters any features programmed on the ICIDsubscriber's telephone line, e.g., call waiting, call forwarding, etc.

FIG. 3 is an ICID call flow diagram in which the ICID subscriber electsto accept the incoming telephone call. At step 101, a telephone call isplaced to an ICID subscriber. A TAT in the terminating CO SSP 20 causesthe call to be suspended at the SSP 20. The trigger also causes the SSP20 to transmit an AIN query message including the CPN (if available) andCDN via the SS7 network and the appropriate STPs 65 to the ICIDsubscriber's serving ISCP 40 at step 102. At step 103, the ISCP 40 sendsa GetData query to the RS 80 with the called party's telephone number torequest the online status of the ICID subscriber. At step 104, the ISCP40 sets a timer equal to a predetermined time, e.g., 2 seconds. In theevent that the RS 80 does not respond within the predetermined time(indicating a timeout condition) or responds with an error, the ISCP 40sends an Authorize Termination response to the SSP 20. As a result, theSSP 20 terminates the suspended telephone call at the subscriber's lineand the call may encounter features programmed on the line, e.g., callwaiting, call forwarding, etc.

If the subscriber is online with ICID service active, the RS 80 respondswith a “1” indicating the subscriber is online. The RS 80 also respondswith the IP is address, port number, and subscriber key information forthe ICID subscriber's Internet session. In this scenario, because thesubscriber is online with ICID turned ON, the RS 80 responds to the ISCP40 at step 105 with a “1”. At step 106, a check is performed at the ISCP40 to determine whether the subscriber has voice mail service.

Also at step 106, a check is performed at the ISCP 40 to determinewhether the Presentation Restriction (PR) value is restricted orunavailable. If the Presentation Restriction value is restricted and thecalled party subscribes to Anonymous Call Rejection (ACR) service, anAuthorize Termination response is sent to the SSP 20 allowing the callto be rejected. ACR prevents calls to subscribers when a calling partyblocks their number.

If the calling party number was delivered with the query and thePresentation Restriction indicator for the incoming call is allowed, theISCP 40 launches a query to the Local Number portability database todetermine whether the received CPN is ported. The telephone numberreturned in the response is either equal to the CPN sent in the query ifthe telephone number is not ported or the Local Routing Number (LRN) ifthe telephone number is ported. The Telephone number from the responseis used as the CPN and checked against entries in a table to determineif the NPA-NXX belongs to a participating Local Exchange Carrier (LEC).A participating LEC is one that provides data from their LIDB, or allowsaccess to their LIDB.

If the CPN is found to be a participating LEC, a GetData query islaunched to the LIDB 50 at step 107 to retrieve the calling party'sname. If the CPN was not delivered with the query, or there is noparticipating LEC, or the Presentation Restriction indicator for theincoming call is anonymous or unavailable, the ISCP 40 will not launch aGetData query to the LIDB 50 to retrieve the calling party's name. Inthis event, the calling party name is null in the InvokeApp query to theICWS 70. If available, the calling party's name is sent to the ISCP 40from the LIDB 50 at step 108.

At step 109, the ISCP 40 instructs the SSP 20 to play a “please hold”announcement to the calling party to request the calling party to holdthe line (step 110). At step 111, the ISCP 40 sends an InvokeApp requestto the ICWS 70. The request contains the CDN, CPN (if available and notpresentation restricted), the calling party name (if available and notpresentation restricted), IP address, port number, client softwareversion, and an indicator as to whether or not the ICID subscriber hasvoice mail service.

At step 112, the ISCP 40 sets a timer equal to a predetermined time,e.g., 25 seconds. In the event that the ICWS 70 does not respond withinthe predetermined time (indicating a timeout condition) or responds withan error, the ISCP 40 instructs the SSP 20 to stop playing the “pleasehold” announcement to the caller. Then, the SSP 20 begins playing anannouncement to the caller. When voice mail is available, the messageinforms the caller that the call is being forwarded to a voice mailservice. Lastly, the ISCP 40 sends an Authorize Termination response tothe SSP 20. If the subscriber does not have voice mail service, an erroris reported and the ISCP 40 sends an Authorize Termination response tothe SSP 20. As a result, the SSP 20 terminates the suspended telephonecall to the subscriber's telephone line and the call encounters anyother features programmed on the line, e.g., call waiting, callforwarding, etc.

If no timeout occurs, at step 113 the ICWS 70 sends a message via theInternet 100 to the ICID subscriber, which appears on the subscriber'sdisplay, informing the subscriber of the incoming call and presentingthe subscriber with disposition options for the call. The messagedisplayed may be a pop-up dialog is box. At step 114, the ICIDsubscriber elects to accept the telephone call, and as a result, theclient software 22 responds to the ICWS 70 with option 1 and will send ade-registration message to the RS 80, and begin to terminate thesubscriber's Internet session. The ICWS 70 passes the subscriber'soption 1 selection to the ISCP 40 at step 115. At step 116, the ISCP 40instructs the SSP 20 to stop playing the “please hold” announcement tothe caller. At step 117, the “please hold” announcement is terminated bythe SSP 20 and at Step 118, the SSP 20 sends a Resource Clear message tothe ISCP 40 confirming that the message is no longer playing. At step119, the ISCP 40 instructs the SSP 20 to begin playing a “will take yourcall” announcement to the caller (step 120). At step 121, the SSP 20sends a Resource Clear message to the ISCP 40. At the conclusion of the“will take your call” announcement, the ISCP 40 sends an AuthorizeTermination response to the SSP 20 which terminates the suspended callto the subscriber's telephone line (steps 122-123). That is, the callingparty is connected to the subscriber.

FIG. 4 is an ICID call flow diagram in which the ICID subscriber electsto forward the incoming telephone call to voice mail service. At step201, a telephone call is placed to an ICID subscriber. A TAT in theterminating CO SSP 20 causes the call to be suspended at the SSP 20. Thetrigger also causes the SSP 20 to transmit an AIN query messageincluding the CPN (if available) and CDN via the SS7 network and theappropriate STPs 65 to the ICID subscriber's serving ISCP 40 at step202. At step 203, the ISCP 40 sends a GetData query to the RS 80 withthe called party's telephone number to request the online status of theICID subscriber. At step 204, the ISCP 40 sets a timer equal to apredetermined time, e.g., 2 seconds. In the event that the RS 80 doesnot respond within the predetermined time (indicating a timeoutcondition) or responds with an error, the ISCP 40 sends an AuthorizeTermination response to the SSP 20. As a result, the SSP 20 terminatesthe suspended telephone call at the subscriber's line and the call mayencounter features programmed on the line, e.g., call waiting, callforwarding, etc.

If the subscriber is online with ICID service active, the RS 80 respondswith a “1” indicating the subscriber is online. The RS 80 also respondswith the IP address, port number, and subscriber key information for theICID subscriber's Internet session. In this scenario, because thesubscriber is online with ICID turned ON, the RS 80 responds to the ISCP40 at step 205 with a “1”. At step 206, a check is performed at the ISCP40 to confirm that the subscriber has voice mail service.

Also at step 206, a check is performed at the ISCP 40 to determinewhether the Presentation Restriction value is restricted or unavailable.If the Presentation Restriction value is restricted and the called partysubscribes to Anonymous Call Rejection (ACR) service, an AuthorizeTermination response is sent to the SSP 20 allowing the call to berejected.

If the calling party number was delivered with the query and thepresentation restriction indicator for the incoming call is allowed, theISCP 40 launches a query to the Local Number portability database todetermine whether the received CPN is ported. The telephone numberreturned in the response is either equal to the CPN sent in the querywhen the telephone number is not ported or the LRN when the telephonenumber is ported. The telephone number from the response is used as theCPN and checked against entries in a table to determine if the NPA-NXXbelongs to a participating LEC. If the CPN is found to be aparticipating LEC, a GetData query is launched to the LIDB 50 at step207 to retrieve the calling party's name. If the CPN was not deliveredwith the query, or there is no participating LEC, or the PresentationRestriction indicator for the incoming call is anonymous or unavailable,the ISCP 40 will not launch a GetData query to the LIDB 50 to retrievethe calling party's name. In this event, the calling party name is nullin the InvokeApp query to the ICWS 70. If available, the calling party'sname is sent to the ISCP 40 from the LIDB 50 at step 208.

At step 209, the ISCP 40 instructs the SSP 20 to play a “please hold”announcement to the calling party to request the calling party to holdthe line at step 210. At step 211, the ISCP 40 sends an InvokeApprequest to the ICWS 70. The request contains the CDN, CPN (if availableand not presentation restricted), the calling party name (if availableand not presentation restricted), IP address, port number, clientsoftware version, and an indicator that the ICID subscriber has voicemail service.

At step 212, the ISCP 40 sets a timer equal to a predetermined time,e.g., 25 seconds. In the event that the ICWS 70 does not respond withinthe predetermined time (indicating a timeout condition) or responds withan error, the ISCP 40 instructs the SSP 20 to stop playing the “pleasehold” announcement to the caller. Then, the SSP 20 begins playing anannouncement to the caller informing the caller that the call is beingforwarded to a voice mail service. Lastly, the ISCP 40 sends anAuthorize Termination response to the SSP 20. If the subscriber does nothave voice mail service, an error is reported and the ISCP 40 sends anAuthorize Termination response to the SSP 20. As a result, the SSP 20terminates the suspended telephone call to the subscriber's line and thecall encounters any other features programmed on the line, e.g., callwaiting, call forwarding, etc.

If no timeout occurs, at step 213 the ICWS 70 sends a message via theInternet 100 to the ICID subscriber, which appears on the subscriber'sdisplay, informing the subscriber of the incoming call and presentingthe subscriber with disposition options for the call. The displayedmessage may be a pop-up dialog box. At step 214, the ICID subscriberelects option 2 to send the incoming telephone call to voice mailservice, and as a result, the client software 22 responds to the ICWS 70and will not terminate the subscriber's Internet session. The ICWS 70passes the subscriber's option 2 selection to the ISCP 40 at step 215.At step 216, the ISCP 40 instructs the SSP 20 to stop playing the“please hold” announcement to the caller. At step 217, the “please hold”announcement is terminated by the SSP 20 and at step 218, the SSP 20sends a Resource Clear message to the ISCP 40 confirming that themessage is no longer playing. At step 219, the ISCP 40 instructs the SSP20 to begin playing a “forwarding to voice mail service” announcement tothe caller (step 220). At step 221, the SSP 20 sends a Resource Clearmessage to the ISCP 40. At the conclusion of the “forwarding to voicemail service” announcement, the ISCP 40 sends an Authorize Terminationresponse to the SSP 20 which terminates the suspended call to thesubscriber's busy telephone line (steps 222-223). As the call attemptsto terminate at the subscriber's line, the call encounters programmingassociated with voice mail service and the call is forwardedaccordingly. Ultimately, the calling party is connected with thesubscriber's voice mail box and has the option of leaving a message.

FIG. 5 is an ICID call flow diagram in which the ICID subscriber electsto send the incoming telephone call to an announcement. At step 301, atelephone call is placed to an ICID subscriber. A TAT in the terminatingCO SSP 20 causes the call to be suspended at the SSP 20. The triggeralso causes the SSP 20 to transmit an AIN query message including theCPN (if available) and CDN via the SS7 network and the appropriate STPs65 to the ICID subscriber's serving ISCP 40 at step 302. At step 303,the ISCP 40 sends a GetData query to the RS 80 with the called party'stelephone number to request the online status of the ICID subscriber. Atstep 304, the ISCP 40 sets a timer equal to a predetermined time, e.g.,2 seconds. In the event that the RS 80 does not respond within thepredetermined time (indicating a timeout condition) or responds with anerror, the ISCP 40 sends an Authorize Termination response to the SSP20. As a result, the SSP 20 terminates the suspended telephone call atthe subscriber's line and the call may encounter features programmed onthe line, e.g., call waiting, call forwarding, etc.

If the subscriber is online with ICID service active, the RS 80 respondswith a “1” indicating the subscriber is online. The RS 80 also respondswith the IP address, port number, and subscriber key information for theICID subscriber's Internet session. In this scenario, because thesubscriber is online with ICID turned ON, the RS 80 responds to the ISCP40 at step 305 with a “1”. At step 306, a check is performed at the ISCP40 to determine whether the subscriber has voice mail service.

Also at step 306, a check is performed at the ISCP 40 to determinewhether the Presentation Restriction value is restricted or unavailable.If the Presentation Restriction value is restricted and the called partysubscribes to Anonymous Call Rejection (ACR) service, an AuthorizeTermination response is sent to the SSP 20 allowing the call to berejected.

If the calling party number was delivered with the query and thepresentation restriction indicator for the incoming call is allowed, theISCP 40 launches a query to the Local Number portability database todetermine whether the received CPN is ported. The telephone numberreturned in the response is either equal to the CPN sent in the query ifthe telephone number is not ported or the LRN if the telephone number isported. The telephone number from the response is used as the CPN andchecked against entries in a table to determine if the NPA-NXX belongsto a participating LEC. If the CPN is found to be a participating LEC, aGetData query is launched to the LIDB 50 at step 307 to retrieve thecalling party's name. If the CPN was not delivered with the query, orthere is no participating LEC, or the Presentation Restriction indicatorfor the incoming call is anonymous or unavailable, the ISCP 40 will notlaunch a GetData query to the LIDB 50 to retrieve the calling party'sname. In this event, the calling party name is null in the InvokeAppquery to the ICWS 70. If available, the calling party's name is sent tothe ISCP 40 from the LIDB 50 at step 308.

At step 309, the ISCP 40 instructs the SSP 20 to play a “please hold”announcement to the calling party to request the calling party to holdthe line at step 310. At step 311, the ISCP 40 sends an InvokeApprequest to the ICWS 70. The request contains the CDN, CPN (if availableand not presentation restricted), the calling party name (if availableand not presentation restricted), IP address, port number, clientsoftware version, and an indicator as to whether or not the ICIDsubscriber has voice mail service.

At step 312, the ISCP sets a timer equal to a predetermined time, e.g.,25 seconds. In the event that the ICWS 70 does not respond within thepredetermined time (indicating a timeout condition) or responds with anerror, the ISCP 40 instructs the SSP 20 to stop playing the “pleasehold” announcement to the caller. Then, the SSP 20 begins playing anannouncement to the caller informing the caller that the call is beingforwarded to a voice mail service. Lastly, the ISCP 40 sends anAuthorize Termination response to the SSP 20. If the subscriber does nothave voice mail service, an error is reported and the ISCP 40 sends anAuthorize Termination response to the SSP 20. As a result, the SSP 20terminates the suspended telephone call at the subscriber's line and thecall encounters any other features programmed on the line, e.g., callwaiting, call forwarding, etc.

If no timeout occurs, at step 313 the ICWS 70 sends a message via theInternet 100 to the ICID subscriber, which appears on the subscriber'sdisplay, informing the subscriber of the incoming call and presentingthe subscriber with disposition options for the call. The messagedisplayed may be a pop-up dialog box.

At step 314, the ICID subscriber elects to send the telephone call to anannouncement, and as a result, the client software 22 responds to theICWS 70 with the announcement selection number, which consists of twochoices. The first message that may be played advises the caller thatthe subscriber is busy and that the caller should call back later. Thesecond option advises the caller that the subscriber is busy and thatthe subscriber will return the call to the caller at a later time.

The ICWS 70 passes the subscriber's option selection to the ISCP 40 atstep 315. At step 316, the ISCP 40 instructs the SSP 20 to stop playingthe “please hold” announcement to the caller. At step 317, the “pleasehold” announcement is terminated by the SSP 20 and at step 318, the SSP20 sends a Resource Clear message to the ISCP 40 confirming that themessage is no longer playing. At step 319, the ISCP 40 instructs the SSP20 to begin playing the selected announcement (step 320). At step 321,the SSP 20 sends a Resource Clear message to the ISCP 40. At theconclusion of the selected announcement, the call is disconnected atstep 322.

FIG. 6 is an ICID call flow diagram in which the ICID subscriber electsto forward the incoming telephone call to another telephone line. Atstep 401, a telephone call is placed to an ICID subscriber. A TAT in theterminating CO SSP 20 causes the call to be suspended at the SSP 20. Thetrigger also causes the SSP 20 to transmit an AIN query messageincluding the CPN (if available) and CDN via the SS7 network and theappropriate STPs 65 to the ICID subscriber's serving ISCP 40 at step402. At step 403, the ISCP 40 sends a GetData query to the RS 80 withthe called party's telephone number to request the online status of theICID subscriber. At step 404, the ISCP 40 sets a timer equal to apredetermined time, e.g., 2 seconds. In the event that the RS 80 doesnot respond within the predetermined time (indicating a timeoutcondition) or responds with an error, the ISCP 40 sends an AuthorizeTermination response to the SSP 20. As a result, the SSP 20 terminatesthe suspended telephone call at the subscriber's line and the call mayencounter features programmed on the line, e.g., call waiting, callforwarding, etc.

If the subscriber is online with ICID service active, the RS 80 respondswith a “1” indicating the subscriber is online. The RS 80 also respondswith the IP address, port number, and subscriber key information for theICID subscriber's Internet session. In this scenario, because thesubscriber is online with ICID turned ON, the RS 80 responds to the ISCP40 at step 405 with a “1”. At step 406, a check is performed at the ISCP40 to determine whether the subscriber has voice mail service.

Also at step 406, a check is performed at the ISCP 40 to determinewhether the Presentation Restriction value is restricted or unavailable.If the Presentation Restriction value is restricted and the called partysubscribes to Anonymous Call Rejection (ACR) service, an AuthorizeTermination response is sent to the SSP 20 allowing the call to berejected.

If the calling party number was delivered with the query andpresentation restriction indicator for the incoming call is allowed, theISCP 40 launches a query to the Local Number portability database todetermine whether the received CPN is ported. The telephone numberreturned in the response is either equal to the CPN sent in the query ifthe telephone number is not ported or the LRN if the telephone number isported. The telephone number from the response is used as the CPN andchecked against entries in a table to determine if the NPA-NXX belongsto a participating LEC. If the CPN is found to be a participating LEC, aGetData query is launched to the LIDB 50 at step 407 to retrieve thecalling party's name. If the CPN was not delivered with the query, orthere is no participating LEC, or the Presentation Restriction indicatorfor the incoming call is anonymous or unavailable, the ISCP 40 will notlaunch a GetData query to the LIDB 50 to retrieve the calling party'sname. In this event, the calling party name is null in the InvokeAppquery to the ICWS 70. If available, the calling party's name is sent tothe ISCP 40 from the LIDB 50 at step 408.

At step 409, the ISCP 40 instructs the SSP 20 to play a “please hold”announcement to the calling party to request the calling party to holdthe line at step 410. At step 411, the ISCP 40 sends an InvokeApprequest to the ICWS 70. The request contains the CDN, CPN (if availableand not presentation restricted), the calling party name (if availableand not presentation restricted), IP address, port number, clientsoftware version, and an indicator as to whether or not the ICIDsubscriber has voice mail service.

At step 412, the ISCP sets a timer equal to a predetermined time, e.g.,25 seconds. In the event that the ICWS 70 does not respond within thepredetermined time (indicating a timeout condition) or responds with anerror, the ISCP 40 instructs the SSP 20 to stop playing the “pleasehold” announcement to the caller. Then, the SSP 20 begins playing anannouncement to the caller informing the caller that the call is beingforwarded to a voice mail service. Lastly, the ISCP 40 sends anAuthorize Termination response to the SSP 20. If the subscriber does nothave voice mail service, an error is reported and the ISCP 40 sends anAuthorize Termination response to the SSP 20. As a result, the SSP 20terminates the suspended telephone call at the subscriber's line and thecall encounters any other features programmed on the line, e.g., callwaiting, call forwarding, etc.

If no timeout occurs, at step 413 the ICWS 70 sends a message via theInternet 100 to the ICID subscriber, which appears on the subscriber'sdisplay, informing the subscriber of the incoming call and presentingthe subscriber with disposition options for the call. The messagedisplayed may be a pop-up dialog box. At step 414, the ICID subscriberelects option 3 to redirect the call to another telephone number, and asa result, the client software 22 responds to the ICWS 70 with option 3and a ten digit “forward to” telephone number as selected by thesubscriber. The ICWS 70 passes the subscriber's option 3 selection andthe selected ten digit “forward to” telephone number to the ISCP 40 atstep 415.

At step 416, the ISCP 40 instructs the SSP 20 to stop playing the“please hold” announcement to the caller. At step 417, the “please hold”announcement is terminated by the SSP 20 and at step 418 the SSP 20sends a Resource Clear message to the ISCP 40 confirming that themessage is no longer playing. At step 419, the ISCP 40 instructs the SSP20 to begin playing a “forwarding to another number” announcement to thecaller (step 20). At step 421, the SSP 20 sends a Resource Clear Messageto the ISCP 40. At the conclusion of the “forwarding to another number”announcement, the ISCP 40 sends a Forward Call response to the SSP 20which initiates the process of forwarding the call to the specifiedtelephone number (steps 422-423). Ultimately, the calling party isconnected to the forwarded number.

FIG. 7 is an ICID call flow diagram in which the caller abandons thetelephone call after a response from the ICWS 70. At step 501, atelephone call is placed to an ICID subscriber. A TAT in the terminatingCO SSP 20 causes the call to be suspended at the SSP 20. The triggeralso causes the SSP 20 to transmit an AIN query message including theCPN (if available) and CDN via the SS7 network and the appropriate STPs65 to the ICID subscriber's serving ISCP 40 at step 502. At step 503,the ISCP 40 sends a GetData query to the RS 80 with the called party'stelephone number to request the online status of the ICID subscriber. Atstep 504, the ISCP 40 sets a timer equal to a predetermined time, e.g.,2 seconds. In the event that the RS 80 does not respond within thepredetermined time (indicating a timeout condition) or responds with anerror, the ISCP 40 sends an Authorize Termination response to the SSP20. As a result, the SSP 20 terminates the suspended telephone call atthe subscriber's line and the call may encounter features programmed onthe line, e.g., call waiting, call forwarding, etc.

If the subscriber is online with ICID service active, the RS 80 respondswith a “1” indicating the subscriber is online. The RS 80 also respondswith the IP address, port number, and subscriber key information for theICID subscriber's Internet session. In this scenario, because thesubscriber is online with ICID turned ON, the RS 80 responds to the ISCP40 at step 505 with a “1”. At step 506, a check is performed at the ISCP40 to determine whether the subscriber has voice mail service.

Also at step 506, a check is performed at the ISCP 40 to determinewhether the Presentation Restriction value is restricted or unavailable.If the Presentation Restriction value is restricted and the called partysubscribes to Anonymous Call Rejection (ACR) service, an AuthorizeTermination response is sent to the SSP 20 allowing the call to berejected.

If the calling party number was delivered with the query and thepresentation restriction indicator for the incoming call is allowed, theISCP 40 launches a query to the Local Number portability database todetermine whether the received CPN is ported. The telephone numberreturned in the response is either equal to the CPN sent in the query ifthe telephone number is not ported or the LRN if the telephone number isported. The telephone number from the response is used as the CPN andchecked against entries in a table to determine if the NPA-NXX belongsto a participating LEC. If the CPN is found to be a participating LEC, aGetData query is launched to the LIDB 50 at step 507 to retrieve thecalling party's name. If the CPN was not delivered with the query, orthere is no participating LEC, or the Presentation Restriction indicatorfor the incoming call is anonymous or unavailable, the ISCP 40 will notlaunch a GetData query to the LIDB 50 to retrieve the calling party'sname. In this event, the calling party name is null in the InvokeAppquery to the ICWS 70. If available, the calling party's name is sent tothe ISCP 40 from the LIDB 50 at step 508.

At step 509, the ISCP 40 instructs the SSP 20 to play a “please hold”announcement to the calling party to request the calling party to holdthe line at step 510. At step 511, the ISCP 40 sends an InvokeApprequest to the ICWS 70. The request contains the CDN, CPN (if availableand not presentation restricted), the calling party name (if availableand not presentation restricted), IP address, port number, clientsoftware version, and an indicator as to whether the ICID subscriber hasvoice mail service.

At step 512, the ISCP 40 sets a timer equal to a predetermined time,e.g., 25 seconds. In the event that the ICWS 70 does not respond withinthe predetermined time (indicating a timeout condition) or responds withan error, the ISCP 40 instructs the SSP 20 to stop playing the “pleasehold” announcement to the caller. Then, the SSP 20 begins playing anannouncement to the caller informing the caller that the call is beingforwarded to a voice mail service. Lastly, the ISCP 40 sends anAuthorize Termination response to the SSP 20. If the subscriber does nothave voice mail service, an error is reported and the ISCP 40 sends anAuthorize Termination response to the SSP 20. As a result, the SSP 20terminates the suspended telephone call at the subscriber's line and thecall encounters any other features programmed on the line, e.g., callwaiting, call forwarding, etc.

At step 513 the ICWS 70 sends a message via the Internet 100 to the ICIDsubscriber, which appears on the subscriber's display, informing thesubscriber of the incoming call and presenting the subscriber withdisposition options for call handling. The message displayed may be apop-up dialog box. At step 514, the ICID subscriber elects a calldisposition option to control the call, and as a result, the clientsoftware 22 responds to the ICWS 70 with the option. The ICWS 70 passesthe subscriber's option selection to the ISCP 40 at step 515.

At step 516, the caller abandons the telephone call by hanging up, inwhich case the SSP 20 stops playing the “please hold” announcement tothe caller at step 517 and at step 518, the SSP 20 sends a ResourceClear message to the ISCP 40 due the abandonment of the telephone callby the caller. At step 519, the ISCP 40 terminates CPR processing.

FIG. 8 is an ICID call flow diagram in which the caller abandons thetelephone call before a response from the ICWS 70. At step 601, atelephone call is placed to an ICID subscriber. A TAT in the terminatingCO SSP 20 causes the call to be suspended at the SSP 20. The triggeralso causes the SSP 20 to transmit an AIN query message including theCPN (if available) and CDN via the SS7 network and the appropriate STPs65 to the ICID subscriber's serving ISCP 40 at step 602. At step 603,the ISCP 40 sends a GetData query to the RS 80 with the called party'stelephone number to request the online status of the ICID subscriber. Atstep 604, the ISCP 40 sets a timer equal to a predetermined time, e.g.,2 seconds. In the event that the RS 80 does not respond within thepredetermined time (indicating a timeout condition) or responds with anerror, the ISCP 40 sends an Authorize Termination response to the SSP20. As a result, the SSP 20 terminates the suspended telephone call atthe subscriber' line and the call may encounter features programmed onthe line, e.g., call waiting, call forwarding, etc.

If the subscriber is online with ICID service active, the RS 80 respondswith a “1” indicating the subscriber is online. The RS 80 also respondswith the IP address, port number, and subscriber key information for theICID subscriber's Internet session. In this scenario, because thesubscriber is online with ICID turned ON, the RS 80 responds to the ISCP40 at step 605 with a “1”. At step 606, a check is performed at the ISCP40 to determine whether the subscriber has voice mail service.

Also at step 606, a check is performed at the ISCP 40 to determinewhether the Presentation Restriction value is restricted or unavailable.If the Presentation Restriction value is restricted and the called partysubscribes to Anonymous Call Rejection (ACR) service, an AuthorizeTermination response is sent to the SSP 20 allowing the call to berejected.

If the calling party number was delivered with the query and thepresentation restriction indicator for the incoming call is allowed, theISCP 40 launches a query to the Local Number portability database todetermine whether the received CPN is ported. The telephone numberreturned in the response is either equal to the CPN sent in the query ifthe telephone number is not ported or the LRN if the telephone number isported. The telephone number from the response is used as the CPN andchecked against entries in a table to determine if the NPA-NXX belongsto a participating LEC. If the CPN is found to be a participating LEC, aGetData query is launched to the LIDB 50 at step 607 to retrieve thecalling party's name. If the CPN was not delivered with the query, orthere is no participating LEC, or the Presentation Restriction indicatorfor the incoming call is anonymous or unavailable, the ISCP 40 will notlaunch a GetData query to the LIDB 50 to retrieve the calling party'sname. In this event, the calling party name is null in the InvokeAppquery to the ICWS 70. If available, the calling party's name is sent tothe ISCP 40 from the LIDB 50 at step 608.

At step 609, the ISCP 40 instructs the SSP 20 to play a “please hold”announcement to the calling party to request the calling party to holdthe line (step 610). At step 611, the ISCP 40 sends an InvokeApp requestto the ICWS 70. The request contains the CDN, CPN (if available and notpresentation restricted), the calling party name (if available and notpresentation restricted), IP address, port number, client softwareversion, and an indicator as to whether the ICID subscriber has voicemail service.

At step 612, the ISCP sets a timer equal to a predetermined time, e.g.,25 seconds. In the event that the ICWS 70 does not respond within thepredetermined time (indicating a timeout condition) or responds with anerror, the ISCP 40 instructs the SSP 20 to stop playing the “pleasehold” announcement to the caller. Then, the SSP 20 begins playing anannouncement to the caller informing the caller that the call is beingforwarded to a voice mail service. Lastly, the ISCP 40 sends anAuthorize Termination response to the SSP 20. If the subscriber does nothave voice mail service, an error is reported and the ISCP 40 sends anAuthorize Termination response to the SSP 20. As a result, the SSP 20terminates the suspended telephone call at the subscriber's line and thecall encounters any other features programmed on the line, e.g., callwaiting, call forwarding, etc.

If no timeout occurs, at step 613, the ICWS 70 sends a message via theInternet 100 to the ICID subscriber which appears on the subscriber'sdisplay, informing the subscriber of the incoming call and presentingthe subscriber with disposition options for the call. The messagedisplayed may be a pop-up dialog box. At step 614, the ICID subscriberelects a call disposition option to control the call, and as a result,the client software 22 responds to the ICWS 70 with the option. At step615, the caller abandons the telephone call by hanging up, in which casethe SSP 20 stops playing the “please hold” announcement to the caller atstep 616 and at step 617, the SSP 20 sends a Resource Clear Message tothe ISCP 40 due the abandonment of the telephone call by the caller. Atstep 618, the ISCP 40 terminates CPR processing, ignoring any responsesfrom the ICWS 70 related to this disconnected call at step 619.

FIGS. 9 and 10 show an exemplary flowchart diagram of the ICID ISCPService Logic, according to an aspect of the present invention.

At step s2, a query, including the called party's telephone number, isreceived by the ISCP 40. At step s4, a table is used to derive the LocalAccess and Transport Area (LATA) number based upon the NPA-NXX of thecalled party number. The LATA is used to determine the corresponding RSand ICWS to query for the GetData and InvokeApp requests. That is, thesystem selects an assigned RS & ICWS from multiple RSs and ICWSs, whicheach serve a predetermined area. Subsequently, at step s6 the ISCP 40launches a GetData query to the appropriate RS to obtain thesubscriber's online status and sets a timer equal to a predeterminedtime, e.g., 2 seconds.

If the GetData request is unsuccessful, an error is reported and theISCP 40 instructs the SSP 20 to terminate the suspended call to thesubscriber's line. If however, the GetData request is successful, thesubscriber's online status is determined. If the subscriber is notonline, the ISCP 40 instructs the SSP 20 to terminate the suspended callto the subscriber's line at step s8 and the logic ends at step s9. Ifthe subscriber is online, a determination is made to ascertain whetherthe PR value is restricted or unavailable, at step s10.

If the PR indicator for the incoming call is “allowed”, the ISCP 40launches a query to the LNP database to determine whether the receivedCPN is a ported telephone number. If the query is successful, thetelephone number returned in the response is either equal to the CPNsent in the query if the telephone number is not ported, or the LRN ifthe telephone number is ported. If the query is not successful, an erroris reported, the calling party name is set to null, and a determinationis made as to whether the subscriber has voice mail service. Next, atstep s14 a “please hold” announcement is played to the caller. If thesubscriber has voice mail service, the caller is advised that the calledparty is on another call and that the caller should wait, and that thewait may take fifteen seconds. If the subscriber does not have voicemail service, the caller is advised that the called party is on anothercall, and that if the caller's call is not taken, the caller may hear abusy signal or be transferred to another number.

If the query is successful, the telephone number from the response isused as the CPN and checked against entries in a table to determine ifthe NPA-NXX belongs to a participating LEC, in which case a GetDataquery is launched to the LIDB 50 to retrieve the calling party's name atstep s12. If the GetData query is not successful, an error is reported,the calling party name is set to null, and a determination is made as towhether the subscriber has voice mail service. Next, at step s14 a“please hold” announcement is played to the caller. If the subscriberhas voice mail service, the caller is advised that the called party ison another call and that the caller should wait, and that the wait maytake fifteen seconds. If the subscriber does not have voice mailservice, the caller is advised that the called party is on another call,and that if the caller's call is not taken, the caller may hear a busysignal or be transferred to another number.

If the calling party name and number are retrieved at the LIDB 50, adetermination is made as to whether the subscriber has voice mailservice. Next, at step s14 a “please hold” announcement is played to thecaller. An appropriate message is played, depending on whether thesubscriber has voice mail service.

If the calling party name is not in the LIDB 50, an error is reported,the calling party name is set to null, and a determination is made as towhether the subscriber has voice mail service. Next, at step s14 a“please hold” announcement is played to the caller. An appropriatemessage is played, depending on whether the subscriber has voice mailservice.

If a call is received with a PR indicator of restricted (anonymous) andthe ICID subscriber has the ACR feature activated, an Authorizationresponse is sent to the SSP and the suspended call attempts to terminateat the subscriber's line. If no ACR feature is active, or if the PRvalue is unavailable, the calling party name is set to null and the CPNis set to anonymous or unavailable. Next, at step s14 a “please hold”announcement is played to the caller. An appropriate message is played,depending on whether the subscriber has voice mail service.

At step s16, the ISCP 40 sends an InvokeApp request to the ICWS 70containing the CDN, CPN (if available and not presentation restricted),the calling party name (if available and not presentation restricted),IP address, port number, client software version number, and anindicator as to whether the subscriber has voice mail service. If theICWS 70 does not respond within a predetermined time period, e.g., 25seconds (indicating a timeout condition), an error is reported and anAuthorization Response will be sent to the SSP 20 and the suspended callwill attempt to terminate at the subscriber's line. If, however, theICWS 70 responds within the predetermined time period, a determinationis made as to whether the caller has abandoned the call at step s18, inwhich case the connection is disconnected at step s20. If the caller isstill on the line, the ICWS 70 then formats an Internet message to theclient software 22 on the ICID subscriber's PC 25, which causes a pop-upbox dialog box to be displayed on the subscriber's display 24, informingthe subscriber of the incoming call and presenting the subscriber withseveral call disposition options.

Reference is now made to FIG. 10, which continues the flow of FIG. 9.

A check is made at step s22 to determine whether the subscriber selecteda call disposition option and the please hold announcement isterminated. If no call disposition option is made, the call is forwardedto voice mail service, if available. If the subscriber does not havevoice mail service, an error is reported, an Authorize Terminationresponse is sent to the SSP 20 and the call will attempt to terminate atthe subscriber's line. If the subscriber selects a call dispositionoption, the caller is advised via an announcement of the calldisposition instructions and the call is processed accordingly.

If the subscriber elects to accept the incoming call (step s24), theISCP 40 instructs the SSP 20 to begin playing a “will take your call”announcement at step s30, after which the ISCP 40 sends an AuthorizeTermination Response to the SSP 20 which terminates the suspended callto the subscriber's telephone line at step s32.

If the subscriber elects to forward the incoming call to voice mailservice (step s26), the ISCP 40 instructs the SSP 20 to begin playing anannouncement to the caller that the call is being forwarded to a voicemail service at step s30, after which the ISCP 40 sends an AuthorizeTermination Response to the SSP 20 at step s32. The call is thenconnected to the subscriber's voice mail service.

If the subscriber elects to forward the incoming call to anothertelephone line (step s28), the ISCP 40 instructs the SSP 20 to beginplaying a “forwarding to another number” announcement at step s30, afterwhich the ISCP 40 sends a Forward Call response to the SSP 20 at steps32. The call is then forwarded to the desired number.

If the subscriber elects to send the incoming call to an announcement,the ISCP 40 instructs the SSP 20 to begin playing the announcementselected by the subscriber at step s30. The first message that may beplayed advises the caller that the subscriber is busy and that thecaller should call back later. The second option advises the caller thatthe subscriber is busy and that the subscriber will call the caller backlater. After the selected announcement is played to the caller, thelogic ends at step s34.

Although the invention has been described with reference to severalexemplary embodiments, it is understood that the words that have beenused are words of description and illustration, rather than words oflimitation. Changes may be made within the purview of the appendedclaims, as presently stated and as amended, without departing from thescope and spirit of the invention in its aspects. Although the inventionhas been described with reference to particular means, materials andembodiments, the invention is not intended to be limited to theparticulars disclosed; rather, the invention extends to all functionallyequivalent structures, methods, and uses such as are within the scope ofthe appended claims.

In accordance with various embodiments of the present invention, themethods described herein are intended for operation as software programsrunning on a computer processor. Dedicated hardware implementationsincluding, but not limited to, application specific integrated circuits,programmable logic arrays and other hardware devices can likewise beconstructed to implement the methods described herein. Furthermore,alternative software implementations including, but not limited to,distributed processing or component/object distributed processing,parallel processing, or virtual machine processing can also beconstructed to implement the methods described herein.

It should also be noted that the software implementations of the presentinvention as described herein are optionally stored on a tangiblestorage medium, such as: a magnetic medium such as a disk or tape; amagneto-optical or optical medium such as a disk; or a solid statemedium such as a memory card or other package that houses one or moreread-only (non-volatile) memories, random access memories, or otherre-writable (volatile) memories. A digital file attachment to email orother self-contained information archive or set of archives isconsidered a distribution medium equivalent to a tangible storagemedium. Accordingly, the invention is considered to include a tangiblestorage medium or distribution medium, as listed herein and includingart-recognized equivalents and successor media, in which the softwareimplementations herein are stored.

Although the present specification describes components and functionsimplemented in the embodiments with reference to particular standardsand protocols, the invention is not limited to such standards andprotocols. Each of the standards for Internet and other packet-switchednetwork transmission (e.g., TCP/IP, UDP/IP, HTML, SHTML, DHTML, XML,PPP, FTP, SMTP, MIME); peripheral control (IrDA; RS232C; USB; ISA; ExCA;PCMCIA), & public telephone networks (ISDN, ATM, xDSL) representexamples of the state of the art. Such standards are periodicallysuperseded by faster or more efficient equivalents having essentiallythe same functions. Accordingly, replacement standards and protocolshaving the same functions are considered equivalents.

1. A non-transitory computer readable medium for storing a computerprogram that allows a user connected to the Internet to receivenotification and caller identification information associated with anincoming call from a calling party to the user, the medium comprising: asending code segment that sends a query to a registration server todetermine an Internet status of the user, the Internet status of theuser comprising whether the user is connected to the Internet; areceiving code segment that receives a response from the registrationserver indicating that the user is connected to the Internet, theregistration server having been updated by a heartbeat server regardingthe Internet status of the user, the heartbeat server having receivedheartbeat messages from client software when the user is connected tothe Internet, the response received from the registration servercomprising an IP address and user information associated with the user'sInternet session; and a notifying code segment that sends a message tothe client software on a device of the user, the message comprisingnotification and caller identification information associated with theincoming call.
 2. The non-transitory computer readable medium accordingto claim 1, wherein the user information associated with the user'sInternet session sent in the response comprises a port number.
 3. Thenon-transitory computer readable medium according to claim 1, whereinthe user information associated with the user's Internet session sent inthe response comprises subscriber key information.
 4. The non-transitorycomputer readable medium according to claim 1, wherein the calleridentification information comprises a name of the calling party.
 5. Thenon-transitory computer readable medium according to claim 1, whereinthe caller identification information comprises a telephone number ofthe calling party.
 6. The non-transitory computer readable mediumaccording to claim 1, wherein the client software provides the user withan indication of the incoming call.
 7. A non-transitory computerreadable medium for storing a computer program that allows a userconnected to the Internet to receive notification and calleridentification information associated with an incoming call from acalling party to the user, the medium comprising: a querying codesegment that queries a registration server to determine an Internetstatus of the user, the Internet status of the user comprising whetherthe user is connected to the Internet; a receiving code segment thatreceives a response from the registration server indicating that theuser is connected to the Internet, the registration server having beenupdated by a heartbeat server regarding the Internet status of the user,the heartbeat server having received heartbeat messages from clientsoftware when the user is connected to the Internet, the responsereceived from the registration server comprising an IP address and userinformation associated with the user's Internet session; a messagesending code segment that sends a message to the client software on adevice of the user, the message comprising notification and calleridentification information associated with the incoming call; and adisposition receiving code segment that receives a disposition selectionof the user, the disposition selection of the user comprising how theuser wants the incoming call to be treated.
 8. The non-transitorycomputer readable medium according to claim 7, wherein when the user'sdisposition selection is to accept the incoming call, the clientsoftware sends a de-registration request to the registration server andterminates the user's connection to the Internet, and the incoming callis terminated to the user.
 9. The non-transitory computer readablemedium according to claim 7, wherein when the user's dispositionselection includes forwarding the call to a voice mail service, theincoming call is terminated to the user and then forwarded to the voicemail service.
 10. The non-transitory computer readable medium accordingto claim 7, wherein when the user's disposition selection includesforwarding the call to another telephone line, the call is forwarded toanother telephone line.
 11. The non-transitory computer readable mediumaccording to claim 7, wherein when the user's disposition selectionincludes playing an announcement to the caller, an announcement isplayed to the caller.
 12. The non-transitory computer readable mediumaccording to claim 11, wherein the announcement comprises advising thecalling party to call the user at a later time.
 13. The non-transitorycomputer readable medium according to claim 11, wherein the announcementcomprises advising the calling party that the user will return the call.14. The non-transitory computer readable medium according to claim 7,wherein the client software provides the user with an indication of theincoming call.
 15. The non-transitory computer readable medium accordingto claim 7, wherein the client software provides the user with a visualand audible alert associated with the incoming call.
 16. Anon-transitory computer readable medium for storing a computer programthat determines an Internet status of a user so that notification andcaller identification information associated with an incoming call canbe provided to the user, the medium comprising: a receiving code segmentthat receives a registration request at a registration server fromclient software when the user connects to the Internet; a storing codesegment that stores information at the registration server associatedwith the Internet status of the user, the Internet status of the usercomprising whether the user is connected to the Internet; a heartbeatreceiving code segment that receives heartbeat messages at a heartbeatserver from the client software; and a message receiving segment thatreceives a message at the registration server when there is aninterruption of the heartbeat messages from the client software, whereinthe user is determined to be connected to the Internet when theheartbeat messages are being received at the heartbeat server.
 17. Thenon-transitory computer readable medium according to claim 16, whereinthe heartbeat server receives a de-registration request from the clientsoftware when the user disconnects from the Internet.
 18. Thenon-transitory computer readable medium according to claim 17, whereinthe de-registration request is received at the heartbeat server from theclient software via an Internet call waiting server.
 19. Thenon-transitory computer readable medium according to claim 16, whereinthe heartbeat server compares information associated with the receivedheartbeat messages with registration information in a memory.
 20. Thenon-transitory computer readable medium according to claim 16, whereinthe registration server sends a heartbeat setup message to the heartbeatserver after the registration server receives the registration request.